chore: extend the default block_proposal_timeout to 4 hours
#5768
Conversation
|
@obycode we are not sure whether the failures we are seeing are due to flakiness (probably) or a bug introduced by this PR (unlikely). In all cases, we are updating the branch, which will re-run the tests. |
Thanks, I'll take a look. I agree, it seems unlikely that any test was inadvertently depending on that timeout, since it was already 10 minutes, but I'll investigate. |
|
Ok, I pushed a commit to fix the flakiness in
You can see the approval arrived just before the timeout, so just a little more time and it would've been fine. I'll bump that from 30s to 60s. I need to take a closer look at |
|
I'm tempted to just bump all 30s timeouts to 60s. |
|
|
| // Check that we aren't missing burn blocks | ||
| // Check that we aren't missing burn blocks (except during the Nakamoto transition) | ||
| let epoch_3 = &naka_conf.burnchain.epochs.unwrap()[StacksEpochId::Epoch30]; | ||
| let bhh = u64::from(tip.burn_header_height); | ||
| test_observer::contains_burn_block_range(220..=bhh).unwrap(); | ||
| let missing = test_observer::get_missing_burn_blocks(220..=bhh).unwrap(); | ||
| let missing_is_error: Vec<_> = missing | ||
| .into_iter() | ||
| .filter(|&i| { | ||
| (i != epoch_3.start_height - 1) || { | ||
| warn!("Missing burn block {} at epoch 3 transition", i); | ||
| false | ||
| } | ||
| }) | ||
| .collect(); | ||
|
|
||
| if !missing_is_error.is_empty() { | ||
| panic!("Missing the following burn blocks: {missing_is_error:?}"); | ||
| } |
There was a problem hiding this comment.
Can you move these checks into a fn check_nakamoto_no_missing_blocks(conf: &Config) function? That way, its reusable between at least these two tests.
Until #5729 is implemented, then there is no point in rejecting a block from a miner, no matter how late it is, since no other miner will ever try to extend into its tenure.
Fixes #5753